The technical field of the invention is that of networks for packet communication and for the transport of multimedia data (audio, video, text) in those networks such as the Internet or local networks of IP (“Internet Protocol”) type.
In the context of the transmission of multimedia data streams over the Internet or over LANs (acronym for “local area network”), a multimedia data server must deliver one or more data streams (of video type, audio type, text type, for example sub-titles, etc.) to one or more clients simultaneously. These clients receive and exploit those data progressively with their reception. For example, the client displays the video and plays the audio progressively as it receives them. This is then referred to as “multimedia streaming”.
Generally, the data constituting these multimedia streams (video, audio, text) may be stored and, possibly, be compressed in advance on the data server (e.g. a multimedia hard disk) or on the contrary be captured and then, possibly, be compressed while streaming (for example in the case of network cameras). These data are then cut up into several pieces of payload data which are packetized by adding a variable number of headers or extensions. These headers and extensions contain in particular checking information associated with the different protocol layers or with the services used. They thus form packets able to be transported to their recipients across the networks. An example of a protocol adapted to the transport of multimedia data streams is RTP (acronym for “Real-time Transport Protocol”) above UDP/IP protocols (UDP being an acronym for “User Datagram Protocol”).
For reasons of efficiency, while avoiding fragmentation of packets by lower protocol layers, these RTP network packets generally have a maximum useful size set by the transport protocol used on the physical network. For example, on a network of “Ethernet” type, the maximum useful size of a packet is generally limited to 1500 bytes. This maximum useful size is shared between the payload data and the set of data headers required by the various protocol layers. For example, after addition of the UDP/IP headers, an RTP packet is thus limited to 1472 bytes.
In order to maximize the useful rate of the network from the point of view of the application, it is important for the payload data to be divided up so as to occupy the greatest possible space in a network packet. The dividing up of the multimedia streams into pieces of payload data may be adapted dynamically, either at encoding, or at packetization. The adaptation at the encoder is possible when the compression is carried out while streaming by modifying, for example, the size of the image portions (“slices”) or audio portions (“samples”). The adaptation at packetization is possible when the latter enables several pieces of payload data to be fragmented or combined in the same network packet (for example as with the “H.264” packetization).
Once they have been divided up, a technique, known to the person skilled in the art, consists of placing the payload data in a buffer memory directly at the right place while leaving sufficient space at the buffer memory beginning to be able to add therein, subsequently, all the headers. The headers are thus added progressively by the various protocol layers without having to copy or move the payload data. This technique is thus efficient in terms of memory resource and processor resource.
The problem is to determine the available size in a network packet for the payload data and the location in the buffer memory starting from where the data should be placed.
Moreover, the server may send the same multimedia data streams to several clients at the same time. For example in multi-unicast, a different unicast communication is established between each client and the server. Each network packet is thus sent sequentially to each of the clients. In this case, the same item of payload data is sent to several different clients and only the headers are adapted to each client. To determine the size of the payload data, account is taken of the header constraints of each of the clients in order for an item of payload data to be sent to all the clients without being moved in memory.
Furthermore, each client may negotiate the use of different services (congestion control service, transmission error correction service based for example either on a retransmission mechanism or on a data redundancy mechanism, for example). These services may require the creation of data substream dependent on the original data stream (for example a retransmission or redundancy data stream in addition to the original stream). These services may also require the addition of supplementary information in header form either in the original stream or in the data substream or in both at the same time. For example, in the case of a retransmission, in case of loss of a packet from the main stream, the lost packet must be resent in an associated stream (which will be designated as a substream). As described in RFC 4588 (“RTP Retransmission Payload Format”, IETF, RFC 4588, July 2006) describing the retransmission mechanism over RTP, a header of two supplementary bytes must also be added to the original payload data to describe the sequence number of the lost original packet. It is thus necessary to provide for this possibility as of the time of dividing up the multimedia data into pieces. In the opposite case, it is possible that the item of multimedia data may not be resent due to lack of space in the network packet.
Furthermore, some of this supplementary information may present a persistent character from one stream to another substream, that is to say that it must be repeated both in the original stream and the associated substream or on the contrary may have a local character (dependent on the stream). In this second case, it is not necessary to repeat them from one stream to a substream. These constraints must also be taken into account to determine the size available for the payload data such that they may be sent to all the clients, stream and substream without requiring fragmentation or memory copying.
It is thus particularly complex to determine at any time the optimum size of the payload data to place in the buffer memories in order to be able to be sent to all the clients in the most efficient way in terms of memory and processor resource and as appropriate for the different services used by each of the clients
The paper “A driver-based approach to protocol stack design” (by Curt Schwaderer, Microware Systems Corp., published in Electronic Engineering Times-India (www.eetindia.co.in) in September 1999) is known which describes an approach enabling network protocol stacks to be designed while improving their efficiency. It proposes that a network services module determine the maximum size of the information to be added at the header and trailer of the network packets by interrogating each of the modules constituting the protocol stack. It performs this operation on creation and at each change of the protocol stack. Thus, when the application sends a message (for example “hello world”), the module of network services may directly allocate two buffer memories that are sufficiently large to contain all the information added respectively at packet headers and trailers by each of the modules constituting the protocol stack. All these modules have to do is then to add their information to those buffer memories without having to make any new memory allocation or copy. The approach described in this paper does not enable different types of headers (persistent or local) to be managed, the presence of data substreams or of several recipients for the same set of payload data.
The article “Full TCP/IP for 8-bit architectures” (by Adam Dunkels, Swedish Institute of Computer Science) published in Proceedings of MobiSys 2003, May 2003 is also known. This paper describes the implementation of two TCP/IP protocol stacks that are adapted, in terms of code size and memory consumption, to operate on 8-bit and 16-bit hardware platforms. It describes in particular in section 5 how the management of the memory and of the buffer memories has been optimized so as to require only a few kilo-bytes of RAM. In particular:                the network packets are placed in buffer memories of fixed size. The size is determined by a configuration option on compilation.        the buffer memories contain sufficient space for the TCP/IP protocol stack to be able to add the packet header information before the payload data, the latter being placed directly at the right place in the buffer memories to avoid later copying and        each buffer memory contains a reference counter. This is incremented each time a new reference to the buffer memory is created by a module and decremented each time that reference is freed. The buffer memory as such is only freed once its reference counter has attained the value “0”. The reference counter thus makes it possible to limit the number of copies from the buffer memory.        
This implementation cannot manage headers of which the size varies depending on the services actually activated by the various recipients or the presence of data substreams.
The patent application US 2009/0028142 “Streaming Data Content In A Network” (of Brian K. Schmidt et al., July 2007) is also known, which describes a system for transmitting encoded data streams in which the generation of the data streams includes the generation of summary information. The summary information is then associated with each of the network packets as a complement to the data themselves. This summary information then enables the receiver of the network packets to process, at least in part, the received packets without having to decode them fully. The summary information is of fixed size and is inserted in each of the packets in the form of one or more headers situated between the RTP header and the payload data. The available space in a network packet is evaluated for the payload data as being the maximum size of the UDP network packet (1472 bytes) less the size of the RTP header (12 bytes) less the size of the summary information (for example a fixed size of 88 bytes). This system does not enable the size of the payload data that is available in a network packet to be managed dynamically according to the services actually activated by the various recipients or the presence of data substreams.